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Abstract 

We examine the practicality for a user of using Answer Set Pro- 
gramming (ASP) for representing logical formalisms. We choose as 
an example a formalism aiming at capturing causal explanations from 
causal information. We provide an implementation, showing the nat- 
uralness and relative efficiency of this translation job. We are inter- 
ested in the ease for writing an ASP program, in accordance with the 
claimed "declarative" aspect of ASP. Limitations of the earlier systems 
(poor data structure and difficulty in reusing pieces of programs) made 
that in practice, the "declarative aspect" was more theoretical than 
practical. We show how recent improvements in working ASP systems 
facilitate a lot the translation, even if a few improvements could still 
be useful. 



1 Introduction 



We examine a few difficulties encountered when trying to translate a logical 
formalism into a running answer set programming (ASP) program, show- 
ing how recent developments in ASP systems are of great help. We are not 
concerned here by complexity matters (also an important matter, for which 
exists a large literature). Rather, we deal with the ease for writing, and 
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more importantly reading (thus modifying easily) programs in ASP for a 
given problem. Indeed, ASP is presented as (and is) a declarative formalism 
where it should be immediate to write a program from a logical formaliza- 
tion of a given problem. In practice, this is rarely as easy as claimed. We 
choose as an example a formalism that we have designed in collaboration with 
Philippe Besnard and Marie-Odile Cordier. This formalism aims at a logi- 
cal formalization of explanations from causal and "is-a" statements. Given 
some information such as "fire causes smoke" and "grey smoke is a smoke", 
if "grey smoke" is established, we want to infer that "fire" is a (tentative) 
explanation for this fact. The formalization [3l H] is expressed in terms of 
rules such as 

"if a causes (3 and 5 isa (3, then a explains S because {a, 6} is possible" . 

Here, a,... may be first order atoms (without function symbols). Thus, 
we can express these rules in a "Datalog" formulation. When various ex- 
planations are possible, some of them can be subsumed by other ones, and 
the set of the solutions should be pruned. This concerns looking for paths 
in some graph and ASP is good for these tasks. There currently exist sys- 
tems which are rather efficient, such as DLV0 [9J or gringo/clasp or clasp e(1. 
Transforming formal rules into an ASP program is easy. ASP should then be 
an interesting tool for researchers when designing a new theoretical formal- 
ization as the one examined here. An ASP program should help examining 
a great number of middle sized examples, and check whether the results are 
in accordance with our expectations. Then if middle sized examples could 
work, a few more optimization techniques could make real sized examples 
work. Since ASP rules are close to a natural language, a final user could 
easily adapt a general framework to his precise needs, without requiring a 
complex specific system. 

Even if ASP allows such direct and efficient translation, a few problems 
complicate the task. 

Firstly, the poor data types available in pure ASP systems is a real draw- 
back. Our rules involve sets. There are many ways to represent sets in 
existing ASP systems. We had designed programs working in this way [TT] 
(for systems not allowing functional terms), by representing a set as follows: 
Expl{I, J, N, E) meaning there exists an "explanation" from I to J with a 
set of conditions which is the set {E / Expl{I , J, N, E)}, where N is an index, 

^ ht t p : / / www . dbai . t uwien .ac.at/proj/dlv/ 
ht tp : / /potassco . sourceforge . net / 
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necessary when M sets of conditions exist (A^ G {1, ■ ■ ■ , M}). However, the 
program is rather hard to read, and thus to be adapted. Part of this difficulty 
comes from the second drawback given now. 

Secondly, in pure ASP, it is hard to reuse part of a program. Similar 
rules should be written again, in a slightly different way. Thus, e.g. the 
rules necessary to deal with sets should be rewritten in many parts of the 
full program. 

Thirdly, there are restrictions concerning "brave" or "cautious" reasoning. 
In ASP, "the problem is the program" and the solution consists in one or 
several sets of atoms satisfying the problem. Each such set is an answer 
set. These answer sets are the "ASP models". Brave (respectively cautious) 
solutions mean to look for atoms true in some answer set (respectively all 
the answer sets). In the existing ASP systems, this is generally possible, but 
in a restricted way only. 

All these difficulties make that in practice, the claimed advantage in 
favour of the use of ASP is not so clear when the final program is writ- 
ten. The rules in the program are encumbered by various tricks necessary to 
overcome these limitations, and any subsequent modification in the program 
becomes complex. 

However, things are evolving. To take the example of DLV, points 1 
and 2 above are partly solved: DLV-Complejn deals with the data structure 
problem, since it admits sets and lists. DLT □ allows the use of "templates" , 
which solves to a great extent the problem for reusing part of a program. 
It is not yet possible to use these two improvements together. Since here 
the most problematic case was due to the use of sets, we have used DLV- 
Complex, without DLT. When DLT will be able to work with DLV-Complex, 
the task will be yet easier. 

In the next section, we present what should be known about our explana- 
tion formalism in order to understand its ASP translation. Then, in section 
131 we describe its ASP translation, explaining the interest, and the drawback, 
of using ASP for this kind of job. Finally, we conclude by a few reasonable 
expectations about the future ASP systems which could help a final user, and 
make ASP a really interesting programming paradigm for such problems. 

^http: / /www. mat. unical.it /dlv-complex 
^ https : / / www . mat . unical . it / ianni / wiki/ dlt 
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2 The causal explanation formalism 



2.1 Preliminaries 

For simplicity, we fully present the prepositional version only. The full for- 
malism, with predicates (without functions) and with an elementary "ontol- 
ogy" has been described in |3l H] . The extension from the prepositional case 
to the general case is not difficult, as will be explained in §3.51 We distinguish 
various types of statements in our formal system: 

C: A theory expressing causal statements. 

E.g. Onjodarm causes HeardJjell or Flu causes Fever ST emperature. 

O: An ontology in the form of a set of IS- A links between two items which 
can appear in a causal statement. 
E.g., Temperature -39 -^js-a FeverJTemperature, 

Temper aturcAl -^is~a FeverJTemperature, 

HeardJoudJbell -^is-a HeardJbell, 

Heard_softJjell -^js-a HeardJjell. 

W: A classical prepositional theory expressing truths (incompatible facts, 
co-occurring facts, . . .). E.g., HeardsoftJjell -iHeardJoudJjell. 

Intuitively, prepositional symbols denote elementary properties describing 
states of affairs, which can be facts or events such as FeverJTemperature, 
Onjalarm, HeardJjell. The causal statements express causal relations be- 
tween facts or events expressed by these prepositional symbols. 

Seme care is necessary when providing these causal and entelegical atoms. 
If "F/m causes FeverJTemperature^^ , we will conclude Flu explains 
Temperature -39 from Temperature -39 -^is-a FeverJTemperature, but we 
cannot state Flu causes Temper atureJ39: we require that the causal infor- 
mation is provided "on the right level" and in this case. Temper atureJ39 is 
not on the right level, since ^^TemperatureJi9" is too norrow with respect to 
our knowledge about flu and temperatures. 

The formal system is meant to infer, from such premises C U O U W, 
formulas denoting explanations. This inference will be denoted he. The 
ontological atoms express some common sense knowledge which is necessary 
to infer these "explanations" . Notice that a feature of our formalism is that 
standard implication alone cannot help to infer explanations [31 H] . 
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In the following, a, . . . denote the propositional atoms and ^, . . . 
denote sets thereof. 

Atoms 

1. Propositional atoms: a, (3, 

2. Causal atoms: a causes (3. 

3. Ontological atoms: a -^is~A 

4. Explanation atoms: a explains j3 because^possible 
An ontological atom reads: a is a ^. 

An explanation atom reads: a is an explanation for (3 because $ is possible. 

Notation: In order to help reading long formulas, explanation atoms are 
sometimes abbreviated as a expl j3 bec-poss 

Formulas 

1. Propositional formulas: Boolean combinations of propositional atoms. 

2. Causal formulas: Boolean combinations of causal or propositional atoms. 

The premises of the inference he, namely C U O U W ^ consist of proposi- 
tional and causal formulas, and ontological atoms (no ontological formulas). 
Notice that explanation atoms cannot occur in the premises. 

The properties of causal and ontological formulas are as follows. 

1. Properties of the causal operator 

(a) Entailing [standard] implication: If a causes (3, then a ^ (3. 

2. Properties of the ontological operator 

(a) Entailing implication: If a ~^js-A (3, then a f3. 

(b) Transitivity: If a -^is-a b and b -^is-a c, then a -^is-a c- 

(c) Reflexivity: c -^is-a c 
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Reflexivity is an unconventional property for an IS-A hierarchy. It is 
included here because it helps keeping the number of inference schemes low 
(note that in the ASP translation we do not need reflexivity). 

W is supposed to include (whether explicitly or via inference) all the 
implications induced by the ontological atoms. For example, if 
HeardJoudJbell -^is-a HeardJbell is in O then 
HeardJoudJbell — )■ HeardJbell is in W. 

Similarly, W is supposed to include all conditionals induced by the causal 
statements in C. For example, if Flu causes Fever -Temperature is in C, 
then Flu — > Fever JTemperature is in W. 

2.2 The formal system 

The above ideas are embedded in a short proof system extending classical 
logic: 

1. Causal atoms entail implication: {a causes /3) ^ {a ^ /3). 

2. Ontological atoms 

(a) entail implication: If /3 -^js-a 7 then 13 'j. 

(b) transitivity: If a -^js-a P and (3 -^js-a 7 then a -^js-a 7- 

(c) reflexivity: a -^is-a ot 

3. Generating the explanation atoms 

(a) Initial case 

If 5 ^is-A S ^is-A 7, and W ^^{aA5), 
then {a causes j3) ^ a expl^ bec-poss {a,5} 

(b) Transitivity (gathering the conditions) If ^ -i A(^ U ^'), 
then (a expl f3 bec-poss $ A /3 expl 7 bec-poss ^) 

— a expl^i bec_poss ($ U ^). 

(c) Simplification of the set of conditions If W \= /\^ ^ \li=i A ^ii 
then f\^^^^ ,„^^^a expl (3 bec-poss {^iU^) a expl (3 bec-poss ^. 

These schemes allow us to obtain the inference patterns evoked in the 
previous section: 
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The most elementary "initial case" applies ( 12c|l upon (15a|) where /3 = 7 = 5, 
together with an obvious simplification (15c]) since a — )■ /3 here, getting: 
If a causes /3 and W ^ -la then a expl /3 bec-poss {a}. 

Two other particular cases read as follows (respectively 7 = 5 and /3 = 6): 
If a causes (3, 6 -^is-a P and ly ^ A 5) then a expl 5 bec-poss {a, 6}. 
If a causes (3, (3 -^is-a 1 and W ^ -la then a expl'-y bec_poss {a}. 

Notice that we do not allow explanation through the opposite ontological 
sequence /3 -^is-a 7 and 6 -^js-a 7 [cf the general formulation [3a] . This is 
from experiences with situations of the kind of those evoked in the prelimi- 
naries, and it is in accordance with the notion of "right level". Suppose we 
would admit these sequences, then if e.g. 

a causes HeardJoudJjell, we would necessarily get the conclusion 
a expl Hear d-so ft jbell bec-poss {a, HeardsoftJbeH}, from the natural data 
HeardJoudJbell -^is-a HeardJbell and Heardsoft-bell -^is-a HeardJ>eU. 
We consider such a conclusion as unwanted in this situation. 

It is possible that some domains of application would need other rules. 
Our rules are intended as a compromise between expressive power, natural- 
ness of description and relatively efficient computability. 

The system is independent of any opinion about the controversial discus- 
sion about transitivity of causation. However, we provide some transitivity 
for explanations (the conditions are gathered then, cf I3bll . 

The simplification rule fl3c]) is powerful and can be considered as of little 
interest with respect to the extra computational cost associated with it. In 
practice, simpler rules could suffice, and our ASP translation implements a 
weaker rule defined as follows: 

[3ct ] If W \= /\^ — {ip} f\^, and a explains f3 because^possible $ 
then a explains (3 because^possible $ — {ip}. 

Notice a minor point: we consider as important to keep a is such a case, 
thus the ASP translation does not apply this simplification (removing a re- 
dundant (f from the set of conditions) when (f = a. 

It is important to introduce the notion of optimal explanation atoms: An 
atom a explains (3 because^possible $ is optimal if there is no explanation 
atom a explains (3 because_possible ^ where W \= ^ while W ^ 
— > A'^'- Keeping only these weakest sets of conditions is particularly 
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useful when the derivation is made only thanks to the part of W coming 
from Points [T] and [2a] above. Indeed, this makes the result easier to read 
in case where many possible explanation atoms exist from a to (3. In this 
case, we are certain to keep all the relevant explanation atoms, even if some 
additional W is introduced afterwards. 



2.3 A generic diagram 

Below an abstract diagram is depicted that summarizes many patterns of 
inferred explanations from various cases of causal statements and -^is-a 
links. The theory is described as follows (see Figure [H with greek letters in 
their latin names): 

a causes (3, a causes f3o, (32 causes 7, (3i causes 7, 

/Sa causes e, 71 causes 6, 73 causes 6, €3 causes 73; 

(3 -^IS-A /32, Pi -^is-A l3, -^is-A /3o, (33 -^IS-A (3l, 

7l -^IS-A 1, 72 -^IS-A 1, 72 -^IS~A 73, 72 -^IS-A C, 

ei -^IS-A ^2 -^IS-A ei -^IS-A ^35 ^2 -^IS-A ^3- 

This example shows various different "explaining paths" from a few given 
causal and ontological atoms. Here there is a first "explaining path" from a 
to 6 (Figure [H see also path (la) on Figure [2]). We get successively: 

a expl P2 bec_poss {a} , a expl •ji bec-poss {a,'yi}, and 




Figure 1: A generic diagram, the theory with a first explaining path 
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a explS bec_poss {a, 71}. 

As another "explaining path", we get: a explS bec_poss {a,/3i,7i}. 

This second path is not optimal since {a, 71} C {a,/3i,7i}. The simpli- 
fying rule produces a expl6 bec-poss {a, 71} from 

a expl S bec-poss {a,/3i,7i} but, from a computational point of view, it can 

be better not to generate the second path at all. 

Here are the four optimal explanation atoms from a to 5 (Fig. [2]): 
(la) a expl 6 bec-poss {a,'yi} (16) a expl 6 bec-poss {a,'y2} 
(2a) a expl S bec-poss {a, /33,ei} {2b) a expl 6 bec-poss {a, /33,e2}- 




Figure 2: Four optimal explanation paths from "alpha" to "delta" 



3 An ASP translation of the formalism 
3.1 Presentation 

We have implemented a program in DLV [9], an implementation of the An- 
swer Set Programming (ASP) formalism p], that takes only a few seconds 
to give all the results cxl expl a2 becjposs $, for all examples of the kind de- 
picted in Fig. [2j The first version [11] used pure DLV, and was encumbered 
with tricks allowing to deal with sets. Now that DLV-Complex exists, the 
new version is simpler. As already written, it does not make full "simplifica- 
tion", however it makes the most important ones. For greater examples, it 
still works, if we omit the simplification/optimization step. We have tried a 
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much greater example, involving two different copies of the example of the 
diagram, linked through an additional small set of data. This ends up with 
an example with more than a hundred symbols and more than 10 different 
explanation atoms for some (/, J). This is not a "real world example" yet, 
but it is not too small, and it shows that we are close to realistic examples. 
Hopefully, the progress in ASP systems will make that in a near future real 
world examples could work. 

As explained below, we have encountered a fourth problem, not listed in 
the "three problems" evoked above. Indeed, for this "big example" , the full 
program, including simplification and testing the set of conditions, did not 
work on our computer (crash after more than one hour...). However, since 
the simplification/optimization step is clearly separated from the first gen- 
erating step, and since the verification is separated also, we have separated 
the program into three successive programs: 

The first one generates explanation atoms (not all of them, but sufficiently 
many to be able to retrieve all the optimal ones from those produced here). 

Then, starting from the results of this first program, a second program 
makes all the relevant simplifications and optimizations, in order to help read- 
ing the set of the solutions. The simplification does not take disjunction into 
account as in the powerful rule in Point [He] in H2.2\ rather it corresponds to 
Point [3cf- When two possible sets $ and \1/ of conditions exist for some (/, J), 
if each E is entailed (defined as above) by some and if the contrary 

is not true, then the explanation atom I expl J bec-poss $ is disregarded, 
only the explanation atom with the weaker condition set I expl J bec_poss ^ 
(the most likely to be satisfied) is kept as a result. This tends to keep only 
optimal explanation atoms defined at the end of §2.21 above, while remain- 
ing efficient enough (similarly to the simplification part, only a reasonably 
efficient part of the formal definition is implemented). This facilitates the 
human reading of the result, and in fact it is almost mandatory with some 
sets of data. 

A third program takes the result of the second one (or directly of the first 
one if the second seems useless) and checks whether the set of conditions is 
satisfied in the answer set considered. In fact, in the formalism, we should 
check if it is true in some answer set. This needs full brave reasoning, which 
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for now is not possible with the running systems. However, in our separated 
programs (not detailed here), it is easier to regroup all the answer sets into a 
unique big one, where the original answer sets are distinguished by an index 
(from 1 to the number of original answer sets). In this way, we can do brave 
and cautious reasoning, and check the set of conditions as described in the 
formalism. 

This exhibits a fourth problem with the existing systems. This problem 
has been addressed in various papers about ASP, but apparently it has not 
yet given rise to a real running system. Indeed, [13] describes a system 
which allows to enumerate the answer sets, which is what we need here. 
However, no running system is referenced in this very interesting paper, which 
describes small, natural and very useful improvements for ASP systems. A 
more recent paper [2] describes a more ambitious system which also deals 
with this point. Hopefully, these very interesting and natural improvements 
will be introduced in available systems in a near future. 

3.2 The generating part: getting the relevant explana- 
tion atoms 

The "answer" of an ASP program is a set of answer sets, that is a set of 
concrete literals satisfying the rules (see e. g. [1] for exact definitions and |9] 
for the precise syntax of DLV). 

The user provides the following data: 
symbol(alpha). for each propositional symbol alpha [mandatory only if the 
symbol does not appear in a causal, ontological or classical atom]. 
cause(alpha,beta). for each causal atom a causes (3, 
ont(alpha,beta). for each ontological atom a -^js-a 
true(alpha). or -true(alpha). for each propositional atom a true or false. 

Causal and propositional formulas must be put in conjunctive normal 
form, in order to be entered as sets of clauses such as 
{-true(epsilonl) v -true(gammal) v -true(gamma2). 
-true(epsilon2) v -true(gammal) v -true(gamma2).} 
for the formula (-lel A -ie2) V -17I V -172; 
or {cause(beta2, gamma) v cause(epsilon3,gamma3).} 
for {(32 causes 7) V (e3 causes 73).. 

Notice that if we really need all the logical models, at least with respect to 
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some prepositional or causal atoms, we must "complete" each propositional 
or causal atom concerned as follows: 

true(alpha) v -true(alpha). or cause(alpha,beta) v -cause(alpha,beta). 

This is generally not necessary, and should be avoided as far as possible 
since it is computationally demanding. 

The interesting result consists in the explanation predicates: 
ecSet(alpha, beta, {alpha, delta, gamma}) represents the explanation atom 
a expl f3 bec-poss {a, 6, 7}. 

Here come the first rules: 
ontt(l,J) :- ont(l,J). ontt(l,K) :- ontt(l,J), ont(J,K). rcfl2b] ^ . 

For the sake of "safety" of some rules, and for defining impCO introduced 
below we may need to define all the symbols, and the ones which can appear 
in an explanation set (suffix "E"). 
symbolE(X) :- cause(X,Y). symbolE(Y) :- cause(X,Y). 
symbolE(X) :- ont(X,Y). symbolE(Y) :- ont(X,Y). 
symbol(X) :- symbolE(X). 

Implication derived from causal and ontological atoms ("s" for "strict"): 
impCO(l,J) :- cause(l,J). impCO(l,J) :- ont(l,J). 

impCO(l,K) :- impCO(l,J), impCO(J,K). impCO(l,l) :- symbolE(l). 
impCOs(l,J) :- impCO(l,J), not impCO(J,l). 

We split the general basic generation rule l3al §2.21 in order to improve the 
computational performances. Indeed, in the first three particular cases, only 
one optimal initial explanation atom in (I, J) exists, thus the computation can 
be simplified. 

ecinit(l,J,E) represents / expl J bec-poss {I,E} where this explanation 
atom is obtained without using the transitivity rule: 
ecinit(l,J,l) :- cause(l,J). ecinit(l,J,l) :- cause(l,X), ontt(J,X), impCO(l,J). 
ecinit(l,J,l) :- cause(l,X), ontt(X,J). 

ecinit(l,J,l) :- cause(l,X), ontt(E,X), ontt(E,J), impCO(l,E). 

The most complicated case (with the two ontological axioms) may lead to 
several explanation atoms from / to J, which requires some complications: 
ecinit3p(l,J,E) :- ecinit(l,E,E), cause(l,X), ontt(E,X), ontt(E,J), not ecinit(l,J,l), 

not ecinit(l,J,J). 

nonecinit(l,J,E) :- ecinit3p(l,J,El), ecinit3p(l,J,E), impCOs(E,El). 
ecinit(l,J,E) :- ecinit3p(l,J,E), not nonecinit(l,J,E). 

[Avoids keeping clearly non optimal ones.] 

Since the set of conditions are singletons or pairs in the initial explanation 
atoms [ecinit], set representation was not required. Real explanation atoms 
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[ecSet] are introduced now, together with exphcit sets which allow a serious 
simplification of the ASP rules. 

Firstly, we initialize ecSet with ecinit [#insert(Setl,E,Set) means in DLV- 
Complex: S et = S etl U {E}]: 
ecSet(l,J,{l}) :- ecinit(l,J,l). 
ecSet(l,J,{l,J}) :- ecinit(l,J,J), not ecSet(l,J,{l}). 
ecSet(l,J,{l,E}) :- ecinit(l,J,E), not ecSet(l,J,{l}), not ecSet(l,J,{l,J}). 

Then comes the translation of Point [3b] §2.21 
ecSet(l,J,Set) :- ecSet(l,K,Setl), not ecSet(l,J,Setl), ecinit(K,J,E2), E2 != K, 

#insert(Setl,E2,Set). 
ecSet(l,J,Set) :- ecSet(l,K,Set), ecinit(K,J,K). 

[Nothing to add in this case, since we know that Set \-c K.] 

And this is enough for getting all the relevant explanation atoms. Only 
a few computational optimization tricks complicate a little bit the writing, 
however, the ASP rules remain very close to the formal rules given in §2.21 

3.3 Optimizing the explanation atoms 

This is the most computationally demanding part. Rigorously, it is not 
mandatory. However, it is important in order to avoid providing too many 
unnecessary explanation atoms which complicate the interpretation of the 
result. 

As a short example, suppose we have following data: 

a causes /3, a causes f3o, [32 causes 7, /3i causes 7, 

P2 -^IS-A /3o, Pi -^IS-A /3, P2 —^IS-A A- 

Then, we get the following explanation atoms concerning (0,7): 
ExpU: a explj bec_poss {a, and Expl2: a expl'j bec-poss {a,/32}- 
Since we have (32 -^is-a (3i, we get (32 — )■ (3i from l2al §2.21 in W, even if 
the user does not provide any exphcit W. Thus, each element in {a, (3i} is 
entailed by some element in {a, (32} and not conversely. Thus, the weaker 
set {a, (3i} is more likely to be satisfied, whatever are the other data, and in 
particular whatever may be an explicit W given as additional data. Thus, it 
is useless, and disturbing, to provide Expl2: ExpU is enough. It happens here 
that ExpU is optimal with the given data. Obviously, in more complex cases 
involving disjunction, the "element wise" test would not be enough to discard 
all the sets of conditions which are too strong for entailment. However, the 
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test described here is a good compromise between efficient computation and 
readability of the result. 

We have tried various other programs providing only the [quasi] optimal 
sets, in order to avoid this "optimizing" part. All of them were much slower: 
it is better to provide first the explanation atoms with a program such as 
the one given in §3.2^ which does not take great care for avoiding superfluous 
answers, and then to prune the set of solutions. 

Here comes the "optimizing part". Remind that not all the simplifica- 
tions or optimizations possible are made. As explained above, only those 
which are easy to compute are made. Indeed, except in artificially compli- 
cated data, most of the simplifications are made in this way, while dealing 
with the tricky cases would make the program too slow for a marginal advan- 
tage. These simplification/optimizations are mandatory in order to facilitate 
human reading, and could be omitted in a purely formal perspective since 
anyway the produced explanation atoms cover all the possible situations. 
The rules are very simple: 

imp(l,J) :- impCO(l,J). (additional predicate imp useless in the version 
presented here). 

Propagating the truth values: 
true(J) :- true(l), imp(l,J). -true(l) :- -true(J), imp(l,J). 

Eliminating sets of conditions which contain another set 
[#subSet(Setl,Set) means Setl C Set and #member(E,Set) means E G Set]: 
toolargeSet(l,J,Set) :- ecSet(l,J,Setl), ecSet(l,J,Set), Setl != Set, 

#subSet(Setl,Set). 
ecSetsmall(l,J,Set) :- ecSet(l,J,Set), not toolargeSet(l,J,Set). 
impC0SetEI(Setl,E2) :- ecSetsmall(l,J,Setl), ecSetsmall(l,J,Set2), 

Setl != Set2, impC0(El,E2), #member(El,Setl), #member(E2,Set2), 

not #member(El,Set2), not #member(E2,Setl). 
nonlmpC0Set(Setl,Set2) :- ecSetsmall(l,J,Setl), ecSetsmall(l,J,Set2), 

Setl != Set2, symbolE(E2), #member(E2,Set2),not #member(E2,Setl), 

not impC0SetEI(Setl,E2). % ( "not #member(E2,Setl)," is optional) 
toostrongSet(l,J,Set) :- ecSetsmall(l,J,Set), ecSetsmall(l,J,Setl), 

Set != Setl, nonlmpCOSet(Setl,Set), not nonlmpCOSet(Set,Setl). 
ecSetRes(l,J,Set) :- ecSetsmall(l,J,Set), not toostrongSet(l,J,Set). 

As a result, we only keep the explanation atoms ecSetRes(l,J,Set) where 
no element can be removed from Set and where no set StrongSet is such that 
ecSet(l,J,StrongSet) and each element of Set is implied (in the meaning of 
impCO) by some element of StrongSet, and not conversely. 
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This program is rather slow: the two programs ( §3.2l and the present 
can be launched together for examples such as in the diagram of §2.31 and for 
slightly larger example, but it is impossible for our "big example" . However, 
it is possible to launch the first program (instantaneous on our examples), 
and then the second one starting with the results of the first one. Then, our 
"big example" is solved in far less than one minute on our computer. 

3.4 Checking the set of conditions 

Finally, the following program starts from the result of the preceding pro- 
grams and checks, in each answer set, whether the set of conditions is satisfied 
or not. This program could also be launched starting from the result of the 
first program (replacing ecSetRes with ecSet), simply superfluous explanation 
atoms would be checked also, and almost no "optimization" would be done. 

The result is given by explVer(l,J,Set): / expl J bec-poss Set where Set is 
satisfiable in the answer set considered ("Ver" stands for "verified"). 
explSuppr(l,J,Set) :- ecSetRes(l,J,Set), -true(E), #member(E,Set). 
explVer(l,J,Set) :- ecSetRes(l,J,Set), not explSuppr(l,J,Set). 

Notice that only "individual" checking is made here, in accordance with 
the requirement that the computational properties remain manageable. In 
each answer set, this check is enough. 

Notice that, as already evoked, in our running split program (not provided 
in full here for lack of space), all the answer sets are put into a single one, 
with an index parameter added for each old answer set. This allows to make 
real cautious reasoning when checking the consistency of the explanation 
sets (and only for this point), in accordance with the formalism. Then, a few 
more rules could be added in order to get results in full accordance with our 
formalism (since e.g. answer sets do not provide all the classical models). 
However, even if these rules are written with care, it seems unlikely that the 
resulting program can run in practice for great examples. As already evoked 
above, if we want to get all the classical models, a possibility is to require 
the completion of all the atoms (propositional or causal) which can provoke 
the existence of various answer sets, by adding the disjunctive rules 

true(alpha) v -true(alpha). and cause(gamma, delta) v -cause(gamma, delta), 
for each of these atoms involved in a non atomic formula. This solution 
is easy to write in the program, but becomes clearly unmanageable from a 
computational point of view since the number of answer sets may explode. 
It is the standard, but not practical, way for getting all the classical models 
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in ASP. Then, together with real cautious reasoning, checking for possible 
consistency of the sets could be made in full accordance with the formalism. 
Notice that it is not always clear whether the intended meaning is better 
rendered by classical models than by answer sets. 

We have taken care to describe all the practical limitations of our solution. 
However, apart from these (generally minor in practice) points, we hope to 
have convinced that ASP is very interesting in order to deal with this kind 
of problem. 

One of the advantages is that if we want to modify a rule of the formalism, 
this can be done easily, since there is a close relation between the formal rules 
and the ASP rules. The main difference between formal rules and the ASP 
rules described above concern the "initial rule" in the first program §3.21 
This difference comes from the fact that we have done our best to provide a 
program running in a reasonable time. This is another interest of using ASP: 
such computational optimizations can be introduced in a relatively natural 
way. Even with these complications, modifying the rules remains easy. 

Also, for the example described here, the gain of using DLV-Complex 
instead of pure DLV (or gringo/claspD) is significant and worth mentioning. 

3.5 Dealing with predicate logic 

For the sake of conciseness we have given the translation of the propositional 
version of our formalism. In fact, this is not a serious concern. Indeed, the 
computational efficiency is similar, since the real tricky points all appear in 
the propositional version. A standard way to deal with predicates in ASP, 
starting from a propositional version, is to add a few parameters represent- 
ing the predicate symbols. As an example, let us consider atoms such as 
heard{bell) or like{beU) or own{student, book) in place of a or /3. In the 
formalism, all we need to do is to replace e. g. facts such as 
heardJ)ell causes on_alarm. by heard{bell) causes on{alarm)., 

and to replace all the rules accordingly. 

In this way, we can also translate the slightly extended ontology described 
in |3]. There, two kinds of parameters are considered for each predicate: the 
ones for which the predicate is essentially universal and the ones for which 
the predicate is essentially existential. Let us suppose that we intend that 
heard is essentially existential with respect to its parameter and like essen- 
tially universal. Intuitively, this means that heard is intended as meaning 
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heard some while like means like all. The ontological information would 
be provided by the user as follows: loudJbell -^is-A{object) bell and 
white-car -^is-A{object) car. 

This would provide the following -^is-a relation between atoms 
heard{bell) -^is-a heard{loudJ)ell) . and 
like{car) -^is-a like{white_car).. 

This means that the ASP formulation would contain the following facts 
and rules: ont_object(loud_bell,bell). ont_object(white_car,car). 
ont([P,X],[P,Y]) :- onekind(P), ont_object(X,Y). and 
ont([P,Y],[P,X]) :- allkind(P), ont_object(X,Y). 

Dealing with lists (denoted inside brackets) of DLV-Complex is conve- 
nient: a small set of ASP rules can deal with predicates of any arity, even if 
we do not describe the full formalism here for the sake of conciseness. 

Propositional parameters would be dealt with the following rule: 
ont([A],[B]) :- ont_object(A,B), propkind(A), propkind(B). 

Let us consider a binary predicate own, with own{student, book) meaning 
that the individual (or object) student (whatever it denotes in our formalism) 
owns the object called book. Here, own{X, Y) is intended to mean: "all X 
own some F' . The following rule (0-0) can deal with this predicate: 
ont([P,X,Y],[P,Xl,Yl]) :- alLonekind(P), ont_obJect(Xl,X), ont_obJect(Y,Yl). 

The user should state the kind of parameters for each predicate, as follows: 
onekind(heard). allkind(like). alLonekind(own). propkind(alpha). 

(A more extensive use of the list notation would allow to write rules deal- 
ing with any arity in a yet more natural way.) 

Writing onekind(heard) means that the classes or objects which can appear 
as parameters of the unary predicate heard of the formal system have adapted 
meaning. In this example, bell may denote the class of some bells considered 
in the situation at hand, loudJ)ell the class of those bells which are loud 
and somejjell could denote a precise loudJbell. Notice that the objects are 
intended to denote either individuals or classes of individuals. 

In this situation the user could add the following atom to the one given 
above about bells: ont_obJect(some_bell,loud_bell). 

As an example, let us consider our binary predicate own, with the known 
informations provided by the user as follows in ASP: 
ont_object(tom, student). ont_object(book,docunnent). 
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Then, the foUowing ontological atoms would be deduced by the system 
(again in ASP notation): 
ont( [own, torn, book], [own, torn, document]) 
ont( [own, student, book], [own, torn, book]) 
ont([own, student, book], [own, torn, docunnent]). 

A predicate for which no "all/one" information is given could be used, 
but it would never give rise to ontological atoms. 

This kind of formulation is in accordance with our requirements for the 
formalism: allowing serious expressiveness while keeping computation man- 
ageable. To this respect, for large examples it can be useful to reduce the 
instantiation size by restricting the parameters which can be used for some 
predicates, by adding not unrestr(P), kindPar(P,X,Y) to the body of the rule 
(0-0). Rules such as the following ones should be added 
unrestr(P) :- not restr(P), pred(P). pred(P) :- onekind(P). , [...allkind(P),...]. 
The user would provide the relevant information about restr and kindPar. 

3.6 Conclusion and future work 

We have shown how a recent version of running ASP systems allow easy 
translation of logical formalisms. The example given here is a formalism 
allowing to infer "explanations" from "causal and ontological" information, 
with two requirements: 1 It must be easy and natural to formalize a given 
situation. 2 Computation should remain as manageable as possible. 

These requirements justify some restrictions of our formalism, in par- 
ticular the fact that we accept only classical atoms inside the causal and 
ontological atoms, without operators such as negation or disjunction. The 
formalism is not restricted to the prepositional case, and, as explained in the 
last subsection, it involves an ontology slightly more general that the rudi- 
mentary one developed in the full ASP description given in the preceding 
subsections. 

From the perspective of existing (and predictable in a near future) ASP 
systems, here are some conclusions that can be drawn: 

The existing recent extensions of ASP systems are a real bonus. It is much 
easier to write the program now than it was a few years ago. More impor- 
tantly perhaps, the difference is even greater when reading such a program. 
Indeed the claimed assertions about ASP, namely that it makes programs 
easy to write and to read, are true only when such extensions are used. 0th- 
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erwise, due to the fact that in practice it is very hard to use some portion of 
a program in different places in a greater program, the real ASP programs 
are either very restricted in their application, or hard to read (and thus to 
evolve). In our opinion, DLV with templates (DLT) solves a serious part 
of this problem. However, on our formalism, it happens that it is DLV- 
Complex, since it accepts sets and lists in a natural and efficient way, which 
has made the difference. Indeed, our formalism involves sets in a non trivial 
way, thus the present program is far more readable than the previous ones, 
in pure DLV. 

From a formal perspective, neither DLV-Complex nor DLT are revolution- 
ary. To a great extent, all they do is add way for writing natural programs 
where pure ASP systems need cumbersome rewritings of parts of the pro- 
grams. Generally, using them does not improve computational efficiency. 
The fact is that they always allow more convenient writing, and particularly 
much easier reading, which changes the life of the programmer. Expert ASP 
programmers were able to use previous ASP systems together with small 
parts of more standard programming, but this was not very attracting for 
most of the potential users of ASP systems. 

So, what can we expect now? 

For now, DLT cannot work together with DLV-Complex, and this is the 
first thing we can expect, hopefully in a very near future, together with 
similar facilities for gringo/clasp and other systems. 

Also, "brave" and "cautious" reasoning do not exist in full generality (to 
our knowledge) in available systems. May be our formalism is an extreme 
example of this point (a mix of cautious and standard reasoning would be 
useful), but in fact this happens to be a serious concern in many circum- 
stances. Again, programmers can redirect the result (the set of all answer 
sets) to a very simple other ASP program, for playing with the answer sets 
in a more or less complex way, but this is not very convenient. In the litera- 
ture, we can encounter various texts about this problem, describing systems 
which solve it in a natural manner, but, to our knowledge, such systems are 
not yet available. Some [meta?] predicates, as described in e.g. |[I3], which 
present a relatively simple and natural way to write programs doing this, 
would suffice in many cases. In this way real brave and cautious reasoning 
could be envisioned, and much more. We hope that this will be the case in 
available systems in a near future. Clearly, dealing with too many answer 
sets cannot be done with huge domains, but there are many cases where it 
would be interesting to have full access to the set of all the answer sets. 
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Here is a last feature that could be interesting. The full program did 
not work for what is called our "great example". However, when split in 
two or three parts, it worked relatively well. In this case the split was very 
easy to do. Could it be that future systems detect such possible split, and 
thus extend their range of application? In our example, computing ecSet 
first, then ecSetRes and finally ecSetVer should be automatized. It seems 
easy to detect such one way dependencies, without retro-action. The great 
difference in practice between launching the three programs together, and 
launching them one after the other, shows that such improvement could have 
spectacular consequences. 

For what concerns our own work, the important things to do are to apply 
the formalism to real situations, and, to this respect, firstly to significantly 
extend our notion of "ontology" towards a real one. 
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